The model version in the spack.yaml has not been updated.
Either update it manually, or comment the following to have it updated and committed automatically:

• !bump major for feature releases
• !bump minor for bugfixes

!bump major

❌ Failed to bump version or commit changes, see https://github.com/ACCESS-NRI/ACCESS-OM2/actions/runs/11212418716 ❌

Token has expired. Will regenerate one tomorrow...considering making it have a longer lifespan 😅

Token has expired. Will regenerate one tomorrow...considering making it have a longer lifespan 😅

Would be good to have a mechanism to remind us when things like this are expiring. Can we generate tokens through an API and set through an API?

🚀 Deploying access-om2 2024.10.0 as prerelease pr82-4

module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-4

🛠️ Using: spack 0.22, spack-packages development, spack-config 2024.07.05

🚀 Deploying access-om2 2024.10.0 as prerelease pr82-5

module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-5

🛠️ Using: spack 0.22, spack-packages development, spack-config 2024.07.05

🚀 Deploying access-om2 2024.10.0 as prerelease pr82-6

module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-6

🛠️ Using: spack 0.22, spack-packages development, spack-config 2024.10.03

Note: the Prerelease succeeded (and is usable), the workflow failed to collect some metadata as the updates to spack-config move directories around. This PR fixes that for future runs: ACCESS-NRI/build-cd#144

🚀 Deploying access-om2 2024.10.0 as prerelease pr82-7

module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-7

🛠️ Using: spack 0.22, spack-packages development, spack-config 2024.10.03

Hi @chrisb13 , @anton-seaice , @dougiesquire , This is ready for testing.

Hi @chrisb13 , @anton-seaice , @dougiesquire , This is ready for testing.

I probably won't do any testing while on leave, but if anyone wants to try run this they can use this config. You'll obviously need to modify the config.yaml to use the prerelease module.

Following @dougiesquire suggestion, we've ran a test using this branch (commit 12761ac56fc9c7fa2c80db17f1b0d8c337724ea2). With small modifications to the config.yaml (thanks @jo-basevi!).

The test ran successfully for five years and produced output from ACCESS-OM2 with WOMBAT legacy in generic tracers.

@pearseb also checked the output. NPP screenshot below.

With small modifications to the config.yaml (thanks @jo-basevi!).

Can we get those modifications into this PR?

The test ran successfully for five years and produced output from ACCESS-OM2 with WOMBAT legacy in generic tracers.

Nice. Was this up for debate?

Can we get those modifications into this PR?

The modifications were small but also made to the config repo' (here) so not sure how they'd be incorporated into this PR..?

Oh sorry, I misspoke. As you quite rightly point out the config repo isn't part of this PR, so ignore me. But you can push changes to that branch, or create a new branch with those changes, to make it easier to test.

But you can push changes to that branch, or create a new branch with those changes, to make it easier to test.

Ok as discussed and above, now on a new branch on my own repo', here:
chrisb13/access-om2-configs@e41c923
Do I put in a pull request? (Does it need to get onto the https://github.com/ACCESS-NRI/access-om2-configs ?)

@chrisb13 feel free to just push to the dougiesquire/1deg_jra55_ryf_wombatlite branch (or submit a PR to it)

@chrisb13, I've just hijacked outdated PR #76 and pushed changes to build a prerelease that hopefully helps with testing:

• Prerelease pr76-26 uses git submodule generic tracers (and MOM5/src/shared FMS and git submodule mocsy)
• Prerelease pr82-7 uses "spackified" generic tracers (and ACCESS "spackified" FMS and mocsy)

Everything else should be the same between the prereleases.

We want to check whether these two prereleases give the same answers and performance. I've updated my ACCESS-OM2 1deg_jra55_ryf_wombatlite test config to use the pr76-26 prerelease. This will hopefully run as is and then this line can be changed to use the pr82-7 prerelease.

@dougiesquire, thanks for clarifying.

I think there's something odd about pr76-26 as a payu setup fails to find the ocean executable..

[cyb561.gadi-login-05: 1deg_jra55_ryf4_dougie]$ payu setup
laboratory path:  /scratch/p73/cyb561/access-om2
binary path:  /scratch/p73/cyb561/access-om2/bin
input path:  /scratch/p73/cyb561/access-om2/input
work path:  /scratch/p73/cyb561/access-om2/work
archive path:  /scratch/p73/cyb561/access-om2/archive
Metadata and UUID generation is disabled. Experiment name used for archival: 1deg_jra55_ryf4_dougie
payu: Found modules in /opt/Modules/v4.3.0
Loading access-om2/pr76-26
  Loading requirement: cice5/2023.10.19 libaccessom2/2023.10.26 mom5/2024.08.23
Loading input manifest: manifests/input.yaml
Loading restart manifest: manifests/restart.yaml
Loading exe manifest: manifests/exe.yaml
Setting up atmosphere
Setting up ocean
Traceback (most recent call last):
  File "/g/data/vk83/apps/payu/1.1.5/bin/payu", line 10, in <module>
    sys.exit(parse())
  File "/g/data/vk83/apps/payu/1.1.5/lib/python3.10/site-packages/payu/cli.py", line 49, in parse
    run_cmd(**args)
  File "/g/data/vk83/apps/payu/1.1.5/lib/python3.10/site-packages/payu/subcommands/setup_cmd.py", line 28, in runcmd
    expt.setup(force_archive=force_archive)
  File "/g/data/vk83/apps/payu/1.1.5/lib/python3.10/site-packages/payu/experiment.py", line 439, in setup
    model.setup()
  File "/g/data/vk83/apps/payu/1.1.5/lib/python3.10/site-packages/payu/models/mom.py", line 66, in setup
    super(Mom, self).setup()
  File "/g/data/vk83/apps/payu/1.1.5/lib/python3.10/site-packages/payu/models/model.py", line 316, in setup
    raise FileNotFoundError(
FileNotFoundError: Executable for ocean model not found on path: /scratch/p73/cyb561/access-om2/bin/fms_ACCESS-OM.x

Working backwards our two commits (yours and mine) are very similar with changes only to the config.yaml (both our commits have the same parent):

Swapping pr76-26 for pr82-7 removes the above error.

Have you been able to run pr76-26?

For reasons that are not clear to me there is an fms build named fms_ACCESS-ESM.x in the access-om2/pr76-26 module. So it looks like the binary might be there with the wrong name ? Or the wrong variant was built ?

Have you been able to run pr76-26?

@chrisb13 I hadn't tried but trying just now I get the same issue.

Something has gone wrong with the environment module for pr76-26 and it includes MOM binaries from an ACCESS-ESM1.6 prerelease (??). I've pinged the release team for help in pr76.

We want to check whether these two prereleases give the same answers

@dougiesquire. An update is here

🚀 Deploying access-om2 2024.10.0 as prerelease pr82-9

module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-9

🛠️ Using: spack 0.22, spack-packages development, spack-config 2024.11.11

@harshula note the errors with rebasing on Model Deployment Repositories. The environment pr82-9 will not reflect the changes accurately.

🚀 Deploying access-om2 2024.10.0 as prerelease pr82-8

module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-8

🛠️ Using: spack 0.22, spack-packages development, spack-config 2024.11.11

Hey all, due to:

• The update to Prerelease versioning (in which we now use number of deployments rather than number of commits, which allows rebasing), and
• The update to Projections in the spack.yaml

Some of the spack environment names may clash for future deployments in this PR. If possible, can we move this to a new PR? Happy to help out if needed.